File: AMIGA.4037 From: jimm@amiga.UUCP (James D. Mackraz) Newsgroups: net.micro.amiga Subject: Re: Fraud And Deceit In The Memory Board Market Date: 10 Jul 86 18:30:03 GMT Reply-To: jimm@homer.UUCP (Jim Mackraz) Organization: Commodore-Amiga Inc., 983 University Ave #D, Los Gatos CA 95030 Lines: 21 Keywords: Let me first say that I haven't had the opportunity to verify the following, but you can test for yourself. We have had reports that the drhystone benchmark runs significantly slower in extended memory than in a 512K machine, if that extended memory is CardCo. Those with CardCo mem, can you check? It would be interesting to measure differences in copying large files from RAM:a to RAM:b for a 512K machine vs. CardCo extended. One guy here claims to have hooked up a scope and observed a "goodly number" of wait states in the CardCo card. Can anyone verify? Flame this spot -> X if your observations are contrary to this second-hand information. go wild. jimm "I have my two megabytes, what's your problem?" File: AMIGA.4044 From: rokicki@Navajo.ARPA (Tomas Rokicki) Newsgroups: net.micro.amiga Subject: Re: Fraud And Deceit (I'm mad as hell) Date: 12 Jul 86 23:30:17 GMT Organization: Stanford University Lines: 27 I've got one of those CardCo boards, and yes, it does slow the machine down something awful. Here are the stats: 512K machine, 1.1 988 dhrystones 1536K machine, 1.1 674 dhrystones Loss 31.8% 512K machine, 1.2 beta II 983 dhrystones 1536K machine, 1.2 beta II 664 dhrystones Loss 32.5% Which means I just paid so many hundreds of dollars to SLOW DOWN MY MACHINE! Now, I've designed memory boards before; it's not that difficult to make the RAM run with no wait states on a 7.2 MHz machine. To slow it down so much seems to indicate that two wait states are being introduced for EVERY MEMORY REFERENCE! This is inexcusable. (So is my use of capitals above, but I'm pissed. I've been working very hard squeezing every ounce of performance out of my programs, and something like this comes out and destroys it all.) File: AMIGA.4056 From: rico@oscvax.UUCP (Rico Mariani) Newsgroups: net.micro.amiga Subject: Re: Fraud And Deceit (I'm mad as hell) Date: 13 Jul 86 19:32:36 GMT Organization: Ontario Science Centre, Toronto Lines: 61 Keywords: Comspec, Dhrystone, Memory Summary: 'Fast' ram is only 1% slower FYI, I ran the same tests on my Amiga with a Comspec memory board and the results were much more encouraging. I only ran the tests once each (OK so I'm lazy... gimme a break) so there is some variance compared to the above figures on an unexpanded Amiga. I used 50000 cycles with no registers on Manx Aztec C with 16 bit integers. The times were collected with my little brother's watch in stopwatch mode. The numbers below have lots of digits after the decimal but I wouldn't really trust them too much. I've also included the actual time that I measured for 50000 cycles. 512K machine, 1.1 975.04 dhrys/sec = 51.28 secs for 50000 cycles 2.5M machine, 1.1 967.49 dhrys/sec = 51.68 secs for 50000 cycles Comparison: 99.23% of top speed = 0.77% Loss 512K machine, 1.2 Beta II 976.56 dhrys/sec = 51.20 secs for 50000 cycles 2.5M machine, 1.2 Beta II 963.58 dhrys/sec = 51.89 secs for 50000 cycles Comparison: 98.67% of top speed = 1.33% Loss As you can see, the times are close enough to each other that the stopwatch method really isn't accurate enough to get a good figure for the difference. This should be good enough for the purpose of this experiment though. Another FYI, the Comspec board uses 500mA in typical (not idle) operation. Remember that's a 2 meg board... I can't tell you too much about the ground plane and such but it passes the "I can't see thru the PC board" test. Then again, maybe the light I was using wasn't bright enough :-) DISCLAIMER: a) The Science Centre doesn't have anything to do with any of this. Leave them alone! b) I've enjoyed a healthy relationship with Comspec for a long time now so my views may or may not be biased because of this. c) I don't know what I'm talking about at the best of times :-) That's all -Rico ...{allegra|ihnp4|decvax|watmath|linus}!utzoo!oscvax!rico File: AMIGA.4082 From: rokicki@navajo.STANFORD.EDU (Tomas Rokicki) Newsgroups: net.micro.amiga Subject: Re: Deceit Date: 16 Jul 86 20:55:57 GMT Organization: Stanford University Lines: 53 Keywords: apology Well, I just received a nice letter in response to my earlier flame, so, after receiving Richard Rodgers' permission, I quote: -------------------------------------------------------- As president of the company that designed the C Ltd. (CardCo) board I offer my humblest apology. It would seem that a last second PAL change did in fact make it into the final product without adequate testing. The problem is currently being fixed, and the boards that did get out will be updated. Not to justify, but to explain how this happened. None of our (10+) beta testers found this problem. The excessive wait states do not occur 100% of the time. Our logic analyzer hard copy was "lucky" enough to catch a one wait state picture. We then shipped 150 or so boards before the problem was caught. You got one of our 150 boards, and reported the problem a day after we had found it. You probably called C Ltd., and were frustrated by the lack of answers you received. Sorry... If you will send me your name, address, and/or phone number, I will personally see that you get an updated PAL as soon as it becomes available. I would also like to stress that the board will probably still run with one wait state. The reason for this wait state is that we had to "glue" an Intel chip onto a Motorolla bus. The Intel chip was chosen because it was the only CMOS DRAM controller we could find. A CMOS chip was necessary to accomadate the internal power specifications. A one wait state memory board will NOT be a problem for 98%+ of our customers, so was approved. Richard N. Rodgers, President Creative Microsystems Inc. 9140 SW Locust Street Tigard, OR 97223 -------------------------------------------------------- Made me feel better, anyway, that something was being done about it. I have also learned that their expansion cage and it's memory card does not require any wait states. I've been getting around the problem somewhat by forcing my programs into chip memory with a linker option. True, one wait state is still perhaps too much, but I'm sure I'll survive until I can afford an expansion cage. -tom File: AMIGA.4121 From: richr@pogo.UUCP (Rich Rodgers) Newsgroups: net.micro.amiga Subject: Re: Deceit Date: 18 Jul 86 15:54:08 GMT Organization: Creative Microsystems Inc. Lines: 71 Keywords: apology CMI also felt that one wait state was too many, but did not want to say the board would run with no wait states until we were *positive* that it could be done. Since talking with Tom, we have found the problem with the C Ltd. board. It turned out not to be a PAL change as we originally suspected, but a strap to the DRAM controller that was incorrectly laid out. I apologize to anyone that has been frustrated by this problem, but realize that we were even more upset than you. The C Ltd. manufacturing line has been down for two-three weeks while we were solving this problem. When you are backlogged in excess of one-thousand units, it is difficult to shut down the manufacturing line. I am convinced that our problems have now been solved and that the C Ltd. aMEGA board is of the highest quality. As a side note,to anybody that wants to make the change quickly, and is handy with a soldering iron. There is a row of straps at the top center of the board next to a large cap. It is currently in the following state. O O O O O O O O O | | | | | | O O O O O O O O O | | | O O O O O O O O O ----------------- 1 2 3 4 5 6 7 8 9 Take a small drill bit or exacto knife and cut strap 5. Then solder a wire so that strap 5 is tied high. Your straps will now look like this: O O O O O O O O O | | | | | | | O O O O O O O O O | | O O O O O O O O O ----------------- 1 2 3 4 5 6 7 8 9 In the above configuration, the aMEGA board will run at NO, ZERO, NONE wait states. (Mandelbrots in 640 * 400 will be *Much* faster than Chip RAM). Since only 150 boards were shipped, I do not know how many people on the net are affected. If you are leary of using a soldering iron, and can be without your board for a few days, send me email and I will let you know how to get it updated. (Even if I have to do the update myself). Richard N. Rodgers, President Creative Microsystems Inc. 9140 SW Locust Street Tigard, OR 97223 tektronix!pogo!richr -- Rich Rodgers tektronix!pogo!richr File: AMIGA.4137 From: rokicki@navajo.STANFORD.EDU (Tomas Rokicki) Newsgroups: net.micro.amiga Subject: Re: Memory board timings Date: 21 Jul 86 00:50:34 GMT Distribution: net Organization: Stanford University Lines: 43 Summary: NEW CardCo Timings I just fixed my CardCo board (my soldering iron is still hot), and these are the new updated timings: 512K machine, 1.1 988 dhrystones 1.5M machine, 1.1 938 dhrystones 94.9% of top speed = 5.1% loss 512K machine, 1.2 Beta II 983 dhrystones 1.5M machine, 1.2 Beta II 933 dhrystones 94.9% of top speed = 5.1% loss So, it's taking about 5% away; sounds like refresh delays. I suspect that this 5% will come back with interest on normal applications which access the disk and therefore use the coprocessors, though. I also decided to run the Mandlebrot set and see what improvement I noticed there. Here are the timings for mse (from the Fish disks) on a 640x200x4 screen, when the reset both window and region menu option is selected, for one scan of the window: 512K machine, 1.1 56m 4s 1.5M machine, 1.1 31m13s Speedup: 1.796 (79.6%) Not bad! -tom